home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1994 August: Tool Chest / Dev.CD Aug 94.toast / Tool Chest / Development Platforms / Macintosh Common Lisp Related / Lisp FAQ 21Sept93 / 1.Intro&References next >
Encoding:
Internet Message Format  |  1993-09-21  |  59.1 KB  |  [TEXT/ttxt]
  1. Subject: FAQ: Lisp Frequently Asked Questions 1/7 [Monthly posting]
  2. Newsgroups: comp.lang.lisp,news.answers,comp.answers
  3. Summary: Introductory Matter and Bibliography of Introductions and References
  4. Distribution: world
  5. Followup-To: poster
  6. Reply-To: lisp-faq@think.com
  7. Approved: news-answers-request@MIT.Edu
  8.  
  9. Archive-name: lisp-faq/part1
  10. Last-Modified: Mon Sep 20 21:10:36 1993 by Mark Kantrowitz
  11. Version: 1.38
  12.  
  13. ;;; ****************************************************************
  14. ;;; Answers to Frequently Asked Questions about Lisp ***************
  15. ;;; ****************************************************************
  16. ;;; Written by Mark Kantrowitz and Barry Margolin
  17. ;;; lisp-faq-1.text -- 60533 bytes
  18.  
  19. This post contains Part 1 of the Lisp FAQ.
  20.  
  21. If you think of questions that are appropriate for this FAQ, or would
  22. like to improve an answer, please send email to us at lisp-faq@think.com.
  23.  
  24. Note that the lisp-faq mailing list is for discussion of the content
  25. of the FAQ posting only.  It is not the place to ask questions about Lisp;
  26. use either the common-lisp@ai.sri.com mailing list or the
  27. comp.lang.lisp newsgroup for that.  If a question appears frequently
  28. in one of those forums, it will get added to the FAQ list.
  29.  
  30. There are currently seven parts to the Lisp FAQ:
  31.    1. Introductory Matter and Bibliography of Introductions and References
  32.    2. General Questions
  33.    3. Common Programming Pitfalls
  34.    4. Lisp Implementations and Mailing Lists
  35.    5. Object-oriented Programming in Lisp
  36.    6. FTP Archives and Resources
  37.    7. Lisp Window Systems and GUIs
  38. All parts are posted to comp.lang.lisp. Part 5 is cross-posted to the
  39. comp.lang.clos newsgroup. 
  40.  
  41. Topics Covered (Part 1):
  42.  
  43.   [1-0]      What is the purpose of this newsgroup?
  44.   [1-1]      What is the difference between Scheme and Common Lisp?
  45.   [1-2]      What documentation is available on Lisp? How can I learn Lisp?
  46.   [1-3]      How can I improve my Lisp programming style and coding efficiency?
  47.   [1-4]      Where can I learn about implementing Lisp interpreters and compilers?
  48.   [1-5]      What does CLOS, PCL, X3J13, CAR, CDR, ... mean? 
  49.   [1-6]      Lisp Job Postings
  50.  
  51. Topics Covered (Part 2):
  52.  
  53.   [2-1]      Is there a GNU-Emacs interface to Lisp?
  54.   [2-2]      When should I use a hash table instead of an association list?
  55.   [2-3]      What is the equivalent of EXPLODE and IMPLODE in Common Lisp?
  56.   [2-4]      Is Lisp inherently slower than more conventional languages such as C?
  57.   [2-5]      Why does Common Lisp have "#'"?
  58.   [2-6]      How do I call non-Lisp functions from Lisp?
  59.   [2-7]      Can I call Lisp functions from other languages?
  60.   [2-8]      I want to call a function in a package that might not exist at
  61.       compile time. How do I do this?  
  62.   [2-9]      What is CDR-coding?
  63.   [2-10]  What is garbage collection?
  64.   [2-11]  How do I save an executable image of my loaded Lisp system?
  65.       How do I run a Unix command in my Lisp?
  66.       How do I get the current directory name from within a Lisp program?
  67.   [2-12]  I'm porting some code from a Symbolics Lisp machine to some
  68.       other platform, and there are strange characters in the code.
  69.       What do they mean?  
  70.   [2-13]  History: Where did Lisp come from?
  71.   [2-14]  How do I find the argument list of a function?
  72.       How do I get the function name from a function object?
  73.   [2-15]  How can I have two Lisp processes communicate via unix sockets?
  74.   [2-16]  How can I create a stream that acts like UNIX's /dev/null
  75.       (i.e., gobbles any output and immediately signals EOF on
  76.       input operations)?
  77.  
  78. Common Pitfalls (Part 3):
  79.  
  80.   [3-0]     Why does (READ-FROM-STRING "foobar" :START 3) return FOOBAR
  81.      instead of BAR?  
  82.   [3-1]     Why can't it deduce from (READ-FROM-STRING "foobar" :START 3)
  83.      that the intent is to specify the START keyword parameter
  84.      rather than the EOF-ERROR-P and EOF-VALUE optional parameters?      
  85.   [3-2]     Why can't I apply #'AND and #'OR?
  86.   [3-3]     I used a destructive function (e.g. DELETE, SORT), but it
  87.      didn't seem to work.  Why? 
  88.   [3-4]     After I NREVERSE a list, it's only one element long.  After I
  89.      SORT a list, it's missing things.  What happened? 
  90.   [3-5]     Why does (READ-LINE) return "" immediately instead of waiting
  91.      for me to type a line?     
  92.   [3-6]     I typed a form to the read-eval-print loop, but nothing happened. Why?
  93.   [3-7]     DEFMACRO doesn't seem to work.
  94.      When I compile my file, LISP warns me that my macros are undefined
  95.      functions, or complains "Attempt to call <function> which is 
  96.      defined as a macro.
  97.   [3-8]     Name conflict errors are driving me crazy! (EXPORT, packages)
  98.   [3-9]     Closures don't seem to work properly when referring to the
  99.      iteration variable in DOLIST, DOTIMES, DO and LOOP.
  100.   [3-10] What is the difference between FUNCALL and APPLY?
  101.   [3-11] Miscellaneous things to consider when debugging code.
  102.   [3-12] When is it right to use EVAL?
  103.   [3-13] Why does my program's behavior change each time I use it?
  104.   [3-14] When producing formatted output in Lisp, where should you put the
  105.      newlines (e.g., before or after the line, FRESH-LINE vs TERPRI,
  106.      ~& vs ~% in FORMAT)?
  107.   [3-15] I'm using DO to do some iteration, but it doesn't terminate. 
  108.   [3-16] My program works when interpreted but not when compiled!
  109.  
  110. Lisp Implementations and Mailing Lists (Part 4):
  111.  
  112.   [4-0]      Free Common Lisp implementations.
  113.   [4-1]      Commercial Common Lisp implementations.
  114.   [4-1a]  Lisp-to-C translators
  115.   [4-2]      Scheme Implementations
  116.   [4-4]      Free Implementations of Other Lisp Dialects
  117.   [4-5]      Commercial Implementations of Other Lisp Dialects
  118.   [4-6]      What is Dylan?
  119.   [4-7]      What is Pearl Common Lisp?
  120.   [4-9]      What Lisp-related discussion groups and mailing lists exist?
  121.   [4-10]  ANSI Common Lisp -- Where can I get a copy of the draft standard?
  122.  
  123. Object-oriented Programming in Lisp (Part 5):
  124.  
  125.   [5-0]      What is CLOS (PCL) and where can I get it?
  126.       How do you pronounce CLOS?
  127.   [5-1]      What documentation is available about object-oriented
  128.       programming in Lisp?    
  129.   [5-2]      How do I write a function that can access defstruct slots by
  130.       name?     I would like to write something like 
  131.       (STRUCTURE-SLOT <object> '<slot-name>).   
  132.   [5-3]      How can I list all the CLOS instances in a class?
  133.   [5-4]      How can I store data and CLOS instances (with possibly circular
  134.       references) on disk so that they may be retrieved at some later
  135.       time?
  136.   [5-5]      Given the name of a class, how can I get the names of its slots?
  137.   [5-6]      Free CLOS software.
  138.  
  139. FTP Resources (Part 6):
  140.  
  141.   [6-0] General information about FTP Resources for Lisp
  142.   [6-1] Repositories of Lisp Software
  143.   [6-3] Publicly Redistributable Lisp Software
  144.   [6-6] Formatting code in LaTeX
  145.   [6-7] Where can I get an implementation of Prolog in Lisp?
  146.  
  147. Lisp Window Systems and GUIs (Part 7):
  148.   [7-1] How can I use the X Window System or other GUIs from Lisp?
  149.   [7-2] What Graphers/Browsers are available?
  150.  
  151. Search for \[#\] to get to question number # quickly.
  152.  
  153. Recent Changes:
  154.  
  155. ;;; 1.36:
  156. ;;;  9-AUG-93 mk    Added LispWorks equivalents to 2-12 and 2-14, thanks to
  157. ;;;            Lawrence G. Mayka.
  158. ;;;  9-AUG-93 mk    Picasso no longer actively supported.
  159. ;;;  9-AUG-93 mk    regexp and interlisp-lisp translator (pkarp) have moved to
  160. ;;;            ftp.ai.sri.com.
  161. ;;; 10-AUG-93 mk    Added Paepcke's book to part 5.
  162. ;;; 10-AUG-93 mk    Added entry on CLiCC to part 4.
  163. ;;;
  164. ;;; 1.37:
  165. ;;; 18-AUG-93 mk    Updated WINTERP email addresses.
  166. ;;; 24-AUG-93 mk    Updated XLISP entry to mention source of Mac port.
  167. ;;; 26-AUG-93 mk    Updated CLISP entry in part 4.
  168. ;;;
  169. ;;; 1.38:
  170. ;;; 13-SEP-93 mk    Added info on Marlais to part 4.
  171. ;;; 15-SEP-93 mk    Added ECoLisp to part 4.
  172. ;;; 20-SEP-93 mk    Added Lisp2Tex to [6-6].
  173. ;;; 20-SEP-93 mk    Clarified the note about the MS Windows version of Procyon
  174. ;;;                 CL.
  175. ;;; 20-SEP-93 mk    Added entry on ITASCA to [5-4].
  176.  
  177.  
  178.  
  179. Introduction:
  180.  
  181. Certain questions and topics come up frequently in the various network
  182. discussion groups devoted to and related to Lisp.  This file/article is
  183. an attempt to gather these questions and their answers into a convenient
  184. reference for Lisp programmers.     It (or a reference to it) is posted
  185. periodically.  The hope is that this will cut down on the user time and
  186. network bandwidth used to post, read and respond to the same questions
  187. over and over, as well as providing education by answering questions
  188. some readers may not even have thought to ask.
  189.  
  190. This is not a Lisp tutorial, nor is it an exhaustive list of all Lisp
  191. intricacies.  Lisp is a very powerful and expressive language, but with
  192. that power comes many complexities.  This list attempts to address the
  193. ones that average Lisp programmers are likely to encounter.  If you are
  194. new to Lisp, see the answer to the question "How can I learn Lisp?".
  195.  
  196. The latest version of this file is available via anonymous FTP from CMU
  197. and Thinking Machines: 
  198.  
  199.    To obtain the files from CMU, connect by anonymous ftp to any CMU CS
  200.    machine (e.g., ftp.cs.cmu.edu [128.2.206.173]), using username
  201.    "anonymous" and password "name@host". The files lisp-faq-1.text,
  202.    lisp-faq-2.text, lisp-faq-3.text, lisp-faq-4.text, lisp-faq-5.text,
  203.    lisp-faq-6.text and lisp-faq-7.text are located in the directory
  204.        /afs/cs.cmu.edu/project/ai-repository/ai/pubs/faqs/
  205.    [Note: You must cd to this directory in one atomic operation, as
  206.    some of the superior directories on the path are protected from
  207.    access by anonymous ftp.] If your site runs the Andrew File System,
  208.    you can just cp the files directly without bothering with FTP.
  209.  
  210.    To obtain the files from Thinking Machines, ftp them from ftp.think.com,
  211.    in the directory /public/think/lisp/. The file faq.text contains all the
  212.    parts of the FAQ in one file. In addition, specific versions of the FAQ
  213.    are available as faq-<version>.text.
  214.  
  215. The FAQ postings are also archived in the periodic posting archive on
  216. rtfm.mit.edu [18.70.0.224]. Look in the anonymous ftp directory
  217. /pub/usenet/news.answers/ in the subdirectory lisp-faq/. If you do not
  218. have anonymous ftp access, you can access the archive by mail server
  219. as well.  Send an E-mail message to mail-server@rtfm.mit.edu
  220. with "help" and "index" in the body on separate lines for more
  221. information.
  222.  
  223. Unless otherwise specified, the Lisp dialect referred to is Common Lisp,
  224. as defined by "Common Lisp: the Language" (aka "CLtL1") as well as
  225. corrections (but not enhancements) from "Common Lisp: the Language, 2nd
  226. Edition" (aka "CLtL2"), both by Guy L. Steele, Jr. and published by
  227. Digital Press. Note that CLtL2 is NOT an official specification for
  228. the language; ANSI Committee X3J13 is preparing such a specification.
  229. See question [4-10] for information on the status of the ANSI
  230. specification for Common Lisp. Enhancements such as CLOS, conditions,
  231. and the LOOP macro will be referred to separately.
  232.  
  233. ----------------------------------------------------------------
  234. Subject: [1-0] What is the purpose of this newsgroup?
  235.  
  236. The newsgroup comp.lang.lisp exists for general discussion of
  237. topics related to the programming language Lisp. For example, possible
  238. topics can include (but are not necessarily limited to):
  239.    announcements of Lisp books and products
  240.    discussion of programs and utilities written in Lisp
  241.    discussion of portability issues
  242.    questions about possible bugs in Lisp implementations
  243.    problems porting an implementation to some architecture
  244. Postings should be of general interest to the Lisp community. See also
  245. question [4-9]. Postings asking for solutions to homework problems are
  246. inappropriate. 
  247.  
  248. Every so often, somebody posts an inflammatory message, such as
  249.    My programming language is better than yours (Lisp vs. C/Prolog/Scheme). 
  250.    Loop (or Series) should/shouldn't be part of the language.
  251. These "religious" issues serve no real purpose other than to waste
  252. bandwidth. If you feel the urge to respond to such a post, please do
  253. so through a private e-mail message. 
  254.  
  255. Questions about object oriented programming in Lisp should be directed
  256. to the newsgroup comp.lang.clos. Similarly, questions about the
  257. programming language Scheme should be directed to the newsgroup
  258. comp.lang.scheme. Discussion of functional programming language issues
  259. should be directed to the newsgroup comp.lang.functional. Discussion
  260. of AI programs implemented in Lisp should sometimes be cross-posted to
  261. the newsgroup comp.ai.
  262.  
  263. ----------------------------------------------------------------
  264. Subject: [1-1] What is the difference between Scheme and Common Lisp?
  265.  
  266. Scheme is a dialect of Lisp that stresses conceptual elegance and
  267. simplicity. It is specified in R4RS and IEEE standard P1178. (See
  268. the Scheme FAQ for details on standards for Scheme.) Scheme is much
  269. smaller than Common Lisp; the specification is about 50 pages,
  270. compared to Common Lisp's 1300 page draft standard. (See question
  271. [4-10] for details on standards for Common Lisp.) Advocates of Scheme
  272. often find it amusing that the Scheme standard is shorter than the
  273. index to CLtL2. 
  274.  
  275. Scheme is often used in computer science curricula and programming
  276. language research, due to its ability to represent many programming
  277. abstractions with its simple primitives. Common Lisp is often used for
  278. real world programming because of its large library of utility
  279. functions, a standard object-oriented programming facility (CLOS), and
  280. a sophisticated condition handling system.
  281.  
  282. See the Scheme FAQ for information about object-oriented programming
  283. in Scheme. 
  284.  
  285. In Common Lisp, a simple program would look something like the
  286. following:
  287.  
  288.    (defun fact (n)
  289.      (if (< n 2)
  290.      1
  291.      (* n (fact (1- n)))))
  292.  
  293. In Scheme, the equivalent program would like like this:
  294.  
  295.    (define fact
  296.      (lambda (n)
  297.        (if (< n 2)
  298.        1
  299.      (* n (fact (- n 1))))))
  300.  
  301. Experienced Lisp programmers might write this program as follows in order
  302. to allow it to run in constant space:
  303.  
  304.    (defun fact (n)
  305.      (labels ((tail-recursive-fact (counter accumulator)
  306.         (if (> counter n)
  307.             accumulator
  308.             (tail-recursive-fact (1+ counter)
  309.                      (* counter accumulator)))))
  310.        (tail-recursive-fact 1 1)))
  311.  
  312. Whereas in Scheme the same computation could be written as follows:
  313.  
  314.    (define fact
  315.      (lambda (n)
  316.        (letrec ((tail-recursive-fact
  317.          (lambda (counter accumulator)
  318.            (if (> counter n)
  319.                accumulator
  320.              (tail-recursive-fact (+ counter 1)
  321.                       (* counter accumulator))))))
  322.            (tail-recursive-fact 1 1))))
  323.  
  324. or perhaps (using IEEE named LETs):
  325.  
  326.    (define fact
  327.      (lambda (n)
  328.        (let loop ((counter n)
  329.           (accumulator 1))
  330.         (if (< counter 2)
  331.         accumulator
  332.           (loop (- counter 1)
  333.             (* accumulator counter))))))
  334.  
  335. Some Schemes allow one to use the syntax (define (fact n) ...) instead
  336. of (define fact (lambda (n) ...)).
  337.  
  338. ----------------------------------------------------------------
  339. Subject: [1-2] What documentation is available on Lisp? 
  340.            How can I learn Lisp?
  341.  
  342. There are several good Lisp introductions and tutorials:
  343.  
  344.    1. David S. Touretzky
  345.       "Common Lisp: A Gentle Introduction to Symbolic Computation"
  346.       Benjamin/Cummings Publishers, Redwood City, CA, 1990. 592 pages.
  347.       ISBN 0-8053-0492-4. 
  348.        Perhaps the best tutorial introduction to the language. It has
  349.        clear and correct explanations, and covers some fairly advanced
  350.        topics. The book is an updated Common Lisp version of the 1984
  351.        edition published by Harper and Row Publishers. 
  352.  
  353.        Three free Lisp educational tools which were used in the book --
  354.        Evaltrace, DTRACE and SDRAW -- are available by anonymous ftp from
  355.        b.gp.cs.cmu.edu:/usr/dst/public/{lisp,evaltrace}. Evaltrace is a
  356.        graphical notation for explaining how evaluation works and is
  357.        described in "Visualizing Evaluation in Applicative Languages" by
  358.        David S. Touretzky and Peter Lee, CACM 45-59, October 1992. DTRACE
  359.        is a "detailed trace" which provides more information than the 
  360.        tracing tools provided with most Common Lisp implementations. SDRAW
  361.        is a read-eval-draw loop that evaluates Lisp expressions
  362.        and draws the result as a cons cell diagram (for both X11 and ascii
  363.        terminals). Also available is PPMX, a tool for pretty printing
  364.        macro expansions.
  365.  
  366.    2. Robert Wilensky
  367.       "Common LISPcraft"
  368.       W. W. Norton, 1986. 500 pages. ISBN 0-393-95544-3.
  369.  
  370.    3. Wade L. Hennessey 
  371.       "Common Lisp"
  372.       McGraw-Hill, 1989. 395 pages.
  373.        Fairly good, but jumps back and forth from the simple to the
  374.        complex rather quickly, with no clear progression in difficulty.
  375.  
  376.    4. Laurent Siklossy
  377.       "Let's Talk LISP"
  378.       Prentice-Hall, NJ, 1976. 237 pages.
  379.        Good introduction, but quite out of date.
  380.  
  381.    5. Stuart C. Shapiro
  382.       "Common Lisp: An Interactive Approach"
  383.       Computer Science Press/W.H. Freeman, New York, 1992.
  384.       ISBN 0-7167-8218-9
  385.  
  386. Other introductions to Lisp include:
  387.  
  388.    1. A. A. Berk.
  389.       "LISP, The Language of Artificial Intelligence"
  390.       Van Nostrand Reinhold, 1985. 160 pages.
  391.  
  392.    2. Paul Y. Gloess.
  393.       "An Alfred handy guide to Understanding LISP"
  394.       Alfred Publishers (Sherman Oaks, CA), 1982. 64 pages.
  395.  
  396.    3. Ward D. Maurer.
  397.       "The Programmer's Introduction to LISP"
  398.       American Elsevier, 1972. 112 pages.
  399.  
  400.    4. Hank Bromley and Richard Lamson.
  401.       "LISP Lore: A Guide to Programming the LISP Machine"
  402.       Kluwer Academic (Boston), 1987. 337 pages.
  403.  
  404.    5. Sharam Hekmatpour.
  405.       "Introduction to LISP and Symbol Manipulation"
  406.       Prentice Hall (New York), 1988. 303 pages.
  407.  
  408.    6. Deborah G. Tatar
  409.       "A programmer's guide to Common Lisp"
  410.       Digital Press, 1987. 327 pages. ISBN 0-932376-87-8.
  411.        Good introduction on Common Lisp for programmers familiar
  412.        with other programming languages, such as FORTRAN, PASCAL, or C.
  413.  
  414.    7. Timothy Koschmann
  415.       "The Common Lisp Companion"
  416.       John Wiley & Sons, 1990. ISBN 0-471-503-8-8.
  417.        Targeted for those with some programming experience who wish to 
  418.        learn draft-ANSI Common Lisp, including CLOS and the CL condition 
  419.        system. Examples progress incrementally from simple numerical 
  420.        calculation all the way to a logic-programming extension to CL.
  421.   
  422. More advanced introductions to Lisp and its use in Artificial
  423. Intelligence include:
  424.  
  425.    1. Peter Norvig.
  426.       "Paradigms of AI Programming: Case Studies in Common Lisp"
  427.       Morgan Kaufmann, 1992. 946 pages. ISBN 1-55860-191-0.
  428.  
  429.     Provides an in-depth exposition of advanced AI programming techniques
  430.     and includes large-scale detailed examples. The book is the most
  431.     advanced AI/Common-Lisp programming text and reference currently
  432.     available, and hence is not for the complete novice.  It focuses on the
  433.     programming techniques necessary for building large AI systems,
  434.     including object-oriented programming, and has a strong performance
  435.     orientation.
  436.  
  437.     The text is marked by its use of "non-toy" examples to illustrate the
  438.     techniques. All of the examples are written in Common Lisp, and copies
  439.     of the source code are available by anonymous ftp from
  440.     unix.sri.com:pub/norvig and on disk in Macintosh or DOS format from
  441.     the publisher. Some of the techniques described include rule-based
  442.     pattern matching (GPS, Eliza, a subset of Macsyma, the Emycin expert
  443.     system shell), constraint propagation and backtracking (Waltz
  444.     line-labelling), alpha-beta search (Othello), natural language
  445.     processing (top-down, bottom-up and chart parsing), logic-programming
  446.     (unification and Prolog), interpreters and compilers for Scheme, and
  447.     object-oriented programming (CLOS).
  448.  
  449.     The examples are also used to illustrate good programming style and
  450.     efficiency. There is a guide to trouble-shooting and debugging Lisp
  451.     programs, a style guide, and a discussion of portability problems.
  452.     Some of the efficiency techniques described include memoization,
  453.     data indexing, compilation, delaying computation, proper use of
  454.     declarations, avoiding garbage collection, and choosing and using the
  455.     correct data structure.
  456.  
  457.     The book also serves as an advanced introduction to Common Lisp, with
  458.     sections on the Loop macro, CLOS and sequences, and some coverage of 
  459.     error handling, series, and the package facility.
  460.  
  461.    2. Eugene Charniak, Christopher K. Riesbeck, Drew V. McDermott
  462.       and James R. Meehan.
  463.       "Artificial Intelligence Programming", 2nd edition.
  464.       Lawrence Erlbaum Associates (Hillsdale, NJ), 1987. 533 pages.
  465.        Provides many nice code fragments, all of which are written
  466.        in Common Lisp. The first half of the book covers topics
  467.        like macros, the reader, data structures, control structures,
  468.        and defstructs. The second half of the book describes
  469.        programming techniques specific to AI, such as
  470.        discrimination nets, production systems, deductive database
  471.        retrieval, logic programming, and truth maintenance.
  472.  
  473.    3. Patrick H. Winston and Berthold K. P. Horn.
  474.       "LISP", 3rd edition.
  475.       Addison-Wesley (Reading, MA), 1989. 611 pages. ISBN 0-201-08319-1
  476.        Covers the basic concepts of the language, but also gives a lot
  477.        of detail about programming AI topics such as rule-based expert
  478.        systems, forward chaining, interpreting transition trees, 
  479.        compiling transition trees, object oriented programming,
  480.        and finding patterns in images. Not a tutorial. Has many
  481.        good examples. Source code for the examples is available by
  482.        anonymous ftp from ftp.ai.mit.edu:/pub/lisp3/. More
  483.        detailed versions are in /pub/ai3/. (The code runs in
  484.        Lucid, Allegro, KCL, GCLisp, MCL, Symbolics Genera. Send mail
  485.        with subject line "help" to ai3@ai.mit.edu for more information.)
  486.  
  487.    4. John R. Anderson, Albert T. Corbett, and Brian J. Reiser.
  488.       "Essential LISP"
  489.       Addison-Wesley (Reading, MA), 1987. 352 pages.
  490.        Concentrates on how to use Lisp with iteration and recursion.
  491.  
  492.    5. Robert D. Cameron and Anthony H. Dixon
  493.       "Symbolic Computing with Lisp"
  494.       Prentice-Hall, 1992, 326 pages. ISBN 0-13-877846-9.
  495.        The book is intended primarily as a third-year computer science
  496.        text. In terms of programming techniques, it emphasizes recursion
  497.        and induction, data abstraction, grammar-based definition of Lisp
  498.        data structures and functional programming style. It uses
  499.        two Lisp languages: 
  500.         (1) a purely functional subset of Lisp called Small Lisp and
  501.         (2) Common Lisp.
  502.        An MS-DOS interpreter for Small Lisp (including source) is
  503.        provided with the book.  It considers applications of Lisp
  504.        to formal symbolic data domains: algebraic expressions,
  505.        logical formulas, grammars and programming languages. 
  506.  
  507.    6. Hasemer and Domingue.
  508.       "Common Lisp Programming for Artificial Intelligence"
  509.       Addison-Wesley, 1989.
  510.  
  511.    7. Steven Tanimoto
  512.       "The Elements of Artificial Intelligence: An Introduction Using Lisp"
  513.       Computer Science Press, Rockville, MD, 1987, 530 pages.
  514.  
  515.    8. Patrick R. Harrison
  516.       "Common Lisp and Artificial Intelligence"
  517.       Prentice Hall, Englewood Clifs, NJ, 1990. 244 pages. ISBN 0-13-155243.
  518.  
  519. General Lisp reference books include:
  520.  
  521.    1. Guy L. Steele
  522.       "Common Lisp: The Language" [CLtL1]
  523.       Digital Press, 1984. 465 pages. ISBN 0-932376-41-X.
  524.  
  525.    2. Guy L. Steele
  526.       "Common Lisp: The Language, 2nd Edition" [CLtL2]
  527.       Digital Press, 1990. 1029 pages. ISBN 1-55558-041-6.
  528.  
  529.    3. Franz Inc. 
  530.       "Common Lisp: The Reference"
  531.       Addison-Wesley, Reading, MA 1988. ISBN 0-201-11458-5
  532.        Entries on Lisp (CLtL1) functions in alphabetical order.
  533.  
  534. Lisp periodicals include:
  535.     
  536.    1. LISP Pointers.
  537.       Published by ACM SIGPLAN six times a year. Volume 1, Number 1
  538.       was April-May 1987. 
  539.       Subscriptions: ACM Members $12; ACM Student Members $7; Non-ACM
  540.       members $25. Mail checks payable to the ACM to ACM Inc., PO Box
  541.       12115, Church Street Station, New York, NY 10249.
  542.  
  543.    2. LISP and Symbolic Computation, Kluwer Academic Press. Volume 1
  544.       was published in 1989. (jlz@lucid.com is the editor).  ISSN 0892-4635.
  545.       Subscriptions: Institutions $169; Individuals $80. Add $8 for
  546.       air mail. Kluwer Academic Publishers, PO Box 322, 3300 AH Dordrecht, 
  547.       The Netherlands, or Kluwer Academic Publishers, PO Box 358, Accord
  548.       Station, Hingham, MA 02018-0358. 
  549.  
  550.       A full table of contents of all published issues, aims and scope, and
  551.       instructions for authors are available by anonymous ftp from
  552.       world.std.com in the files Kluwer/journals/lisp.toc and
  553.       Kluwer/journals/lisp.inf.
  554.  
  555.    3. Proceedings of the biannual ACM Lisp and Functional Programming
  556.       Conference. (First one was in 1980.)
  557.  
  558.    4. Proceedings of the annual Lisp Users and Vendors Conference.
  559.  
  560. Implementation-specific questions:
  561.  
  562.    1. Lucid. See the wizards.doc file that comes with the Lucid
  563.       release. It describes functions, macros, variables and constants that
  564.       are not official parts of the product and are not supported.
  565.       Constructs described in this file include: the interrupt facility, the
  566.       source file recording facility, the resource facility, multitasking,
  567.       writing your own streams, lisp pipes, i/o buffers, the compiler,
  568.       floating-point functions, memory management, debugger information, the
  569.       window tool kit, extensions to the editor, the foreign function
  570.       interface, clos information, delivery toolkit information, and Lucid
  571.       lisp training classes. The wizards.doc file also covers i/o
  572.       constructs, functions for dealing with DEFSTRUCT, functions and
  573.       constants for dealing with procedure objects, functions and constants
  574.       for dealing with code objects, function for mapping objects,
  575.       additional keyword argument to DISKSAVE, function used in the
  576.       implementation of arrays, function for monitor-specific behavior for a
  577.       process, additional keyword argument to RUN-PROGRAM, and load-time
  578.       evaluation.
  579.  
  580. Many books on Scheme are worth reading even if you use Common Lisp,
  581. because many of the issues are similar. Scheme is a simpler language
  582. to learn, so it is often used in introductory computer science
  583. classes.  See the Scheme FAQ for a list of introductions and
  584. references for Scheme. The two key introductions are Abelson and
  585. Sussman's "Structure and Interpretation of Computer Programs" and 
  586. Friedman and Felleisen's "The Little LISPer". 
  587.  
  588. Special Topics:
  589.  
  590.    Garbage Collection:
  591.  
  592.       Wilson, Paul R., "Uniprocessor Garbage Collection Techniques"
  593.       Proceedings of the 1992 International Workshop on Memory Management.
  594.       Springer Lecture Notes #637. Surveys garbage collection techniques. 
  595.       Includes an excellent bibliography. Available by anonymous ftp from
  596.      cs.utexas.edu:pub/garbage/gcsurvey.ps.
  597.       The BibTeX format of the bibliography is also available in this
  598.       directory, along with several other papers. Contact wilson@cs.utexas.edu
  599.       for more info.
  600.  
  601. ----------------------------------------------------------------
  602. Subject: [1-3] How can I improve my Lisp programming style and 
  603.            coding efficiency?
  604.  
  605. There are several books about Lisp programming style, including:
  606.    
  607.    1. Molly M. Miller and Eric Benson
  608.       "Lisp Style and Design"
  609.       Digital Press, 1990. 214 pages. ISBN 1-55558-044-0.
  610.        How to write large Lisp programs and improve Lisp programming 
  611.        style. Uses the development of Lucid CL as an example. 
  612.  
  613.    2. Robin Jones, Clive Maynard, and Ian Stewart.
  614.       "The Art of Lisp Programming"
  615.       Springer-Verlag, 1989. 169 pages.
  616.  
  617.    3. W. Richard Stark.
  618.       "LISP, Lore, and Logic: an algebraic view of LISP
  619.        programming, foundations, and applications"
  620.       Springer-Verlag, 1990. 278 pages. ISBN 0-387-97072-X
  621.        Self-modifying code, self-reproducing programs, etc.
  622.  
  623.    4. CMU CL User's Manual, Chapter 7, (talks about writing
  624.       efficient code). It is available by anonymous ftp from any CMU CS 
  625.       machine (e.g., ftp.cs.cmu.edu [128.2.206.173]) as the file
  626.     /afs/cs.cmu.edu/project/clisp/docs/cmu-user/cmu-user.ps 
  627.       [when getting this file by anonymous ftp, one must cd to 
  628.       the directory in one atomic operation, as some of the superior
  629.       directories on the path are protected from access by anonymous ftp.]
  630.  
  631.    5. See also Norvig's book, SICP (Abelson & Sussman), SAP
  632.       (Springer and Friedman).
  633.  
  634.    6. Hallvard Tretteberg's Lisp Style Guide is available by anonymous
  635.       ftp in ftp.think.com:/public/think/lisp/style-guide.text. There is
  636.       a fair bit of overlap between Hallvard's style guide and the notes
  637.       below and in part 3 of this FAQ.
  638.  
  639.    7. Rajeev Sangal
  640.       "Programming Paradigms in Lisp"
  641.       McGraw-Hill, 1991. ISBN 0-07-054666-5.
  642.  
  643.    8. Rodney A. Brooks.
  644.       "Programming in Common Lisp"
  645.       John Wiley & Sons, New York, 1985. 303 pages. ISBN 0-471-81888-7.
  646.       Chapter 5 discusses Lisp programming style.
  647.  
  648. Here are some general suggestions/notes about improving Lisp
  649. programming style, readability, correctness and efficiency:
  650.  
  651.    General Programming Style Rules:
  652.  
  653.       - Write short functions, where each function provides a single,
  654.     well-defined operation. Small functions are easier to
  655.     read, write, test, debug, and understand.
  656.  
  657.       - Use descriptive variable and function names. If it isn't clear
  658.     from the name of a function or variable what its purpose is,
  659.     document it with a documentation string and a comment. In fact,
  660.     even if the purpose is evident from the name, it is still worth
  661.     documenting your code.
  662.  
  663.       - Don't write Pascal (or C) code in Lisp. Use the appropriate
  664.     predefined functions -- look in the index to CLtL2, or use the
  665.     APROPOS and DESCRIBE functions. Don't put a close parenthesis
  666.     on a line by itself -- this can really aggravate programmers
  667.     who grew up on Lisp. Lisp-oriented text editors include tools
  668.     for ensuring balanced parentheses and for moving across 
  669.     pairs of balanced parentheses. You don't need to stick
  670.     comments on close parentheses to mark which expression they close.
  671.  
  672.       - Use proper indentation -- you should be able to understand
  673.     the structure of your definitions without noticing the parentheses. 
  674.     In general, the way one indents a form is controlled by the
  675.     first symbol of the form. In DEFUNs, for example, one puts the
  676.     symbol DEFUN, the function name, and the argument list all on
  677.     the same line. If the argument list is too long, one can break
  678.     it at one of the lambda keywords. Following the argument list,
  679.     one inserts a carriage return and lists the expressions in the
  680.     body of the definition, with each form starting on its own
  681.     line indented three spaces relative to the open parenthesis of
  682.     the parent (in this case the DEFUN). This general style -- of
  683.     putting all the significant elements of a form on a single
  684.     line, followed by a carriage return and the indented body --
  685.     holds for many Lisp constructs. There are, of course, variations,
  686.     such as keeping the first clause on the same line as the COND
  687.     or CASE symbol, and the rules are relaxed in different ways to
  688.     keep line lengths to a manageable size. If you find yourself having
  689.     trouble fitting everything in even with line breaking and
  690.     relaxing the rules, either your function names are too long or your
  691.     code isn't very modular. You should perceive this as a signal that
  692.     you need to break up your big definitions into smaller chunks, each
  693.     with a clearly defined purpose, and possibly replace long function
  694.     names with concise but apt shorter ones.
  695.  
  696.       - Use whitespace appropriately. Use whitespace to separate
  697.     semantically distinct code segments, but don't use too much
  698.     whitespace. For example,
  699.        GOOD: 
  700.           (defun foo (x y)
  701.         (let ((z (+ x y 10)))
  702.           (* z z)))
  703.  
  704.        BAD: 
  705.           (defun foo(x y)(let((z(+ x y 10)))(* z z)))
  706.  
  707.           (defun foo ( x  y )
  708.         (let ( ( z (+ x y 10) ) )
  709.           ( * z z )
  710.           )
  711.         )    
  712.      Although the Lisp reader and compiler don't care which you
  713.      use, most experienced Lisp programs find the first example much easier
  714.      to read than the last two.
  715.  
  716.        - Don't use line lengths greater than 80 characters. People who
  717.      write code using Zmacs on Symbolics Lisp Machines are notoriously
  718.      guilty of violating this rule, because the CPT6 font allows
  719.      one to squeeze a tremendous amount of code on the display,
  720.      especially if one spreads the code out horizontally. This
  721.      makes it more difficult to read when printed out or read on
  722.      an 80x24 xterm window. In fact, use a line length of 72 characters
  723.      because it leaves a strip of white space at the edge of the window.
  724.  
  725.    The following functions often abused or misunderstood by novices. 
  726.    Think twice before using any of these functions.
  727.  
  728.       - EVAL. Novices almost always misuse EVAL. When experts use
  729.     EVAL, they often would be better off using APPLY, FUNCALL, or
  730.     SYMBOL-VALUE. Use of EVAL when defining a macro should set off
  731.     a warning bell -- macro definitions are already evaluated
  732.     during expansion. See also the answer to question 3-12.
  733.     The general rule of thumb about EVAL is: if you think you need
  734.     to use EVAL, you're probably wrong.
  735.  
  736.       - PROGV. PROGV binds dynamic variables and is often misused in
  737.     conjunction with EVAL, which uses the dynamic environment. 
  738.     In general, avoid unnecessary use of special variables.
  739.     PROGV is mainly for writing interpreters for languages embedded
  740.     in Lisp. If you want to bind a list of values to a list of
  741.     lexical variables, use
  742.         (MULTIPLE-VALUE-BIND (..) (VALUES-LIST ..) ..)
  743.     or
  744.         (MULTIPLE-VALUE-SETQ (..) (VALUES-LIST ..))
  745.     instead. Most decent compilers can optimize this expression. 
  746.     However, use of this idiom is not to be encouraged unless absolutely
  747.     necessary.
  748.  
  749.       - CATCH and THROW. Often a named BLOCK and RETURN-FROM are
  750.     more appropriate. Use UNWIND-PROTECT when necessary.
  751.  
  752.       - Destructive operations, such as NCONC, SORT, DELETE,
  753.     RPLACA, and RPLACD, should be used carefully and sparingly.
  754.     In general, trust the garbage collector: allocate new
  755.     data structures when you need them.
  756.  
  757.    To improve the readability of your code,
  758.  
  759.       - Don't use any C{A,D}R functions with more than two
  760.     letters between the C and the R. When nested, they become
  761.     hard to read. If you have complex data structures, you
  762.     are often better off describing them with a DEFSTRUCT,
  763.     even if the type is LIST. The data abstraction afforded by
  764.     DEFSTRUCT makes the code much more readable and its purpose
  765.     clearer. If you must use C{A,D}R, try to use
  766.     DESTRUCTURING-BIND instead, or at least SECOND, THIRD, 
  767.     NTH, NTHCDR, etc.
  768.  
  769.       - Use COND instead of IF and PROGN. In general, don't use PROGN if
  770.     there is a way to write the code within an implicit
  771.     PROGN. For example, 
  772.        (IF (FOO X)
  773.            (PROGN (PRINT "hi there") 23)
  774.            34)
  775.     should be written using COND instead.
  776.  
  777.       - Never use a 2-argument IF or a 3-argument IF with a second
  778.     argument of NIL unless you want to emphasize the return value;
  779.     use WHEN and UNLESS instead. You will want to emphasize the
  780.     return value when the IF clause is embedded within a SETQ,
  781.     such as (SETQ X (IF (EQ Y Z) 2 NIL)). If the second argument 
  782.     to IF is the same as the first, use OR instead: (OR P Q) rather
  783.     than (IF P P Q). Use UNLESS instead of (WHEN (NOT ..) ..)
  784.     but not instead of (WHEN (NULL ..) ..).
  785.  
  786.       - Use COND instead of nested IF statements. Be sure to check for
  787.     unreachable cases, and eliminate those cond-clauses.
  788.  
  789.       - Use backquote, rather than explicit calls to LIST, CONS, and
  790.     APPEND, whenever writing a form which produces a Lisp form, but
  791.     not as a general substitute for LIST, CONS and APPEND. LIST, 
  792.     CONS and APPEND usually allocate new storage, but lists produced
  793.     by backquote may involve destructive modification (e.g., ,.).
  794.  
  795.       - Make the names of special (global) variables begin and end
  796.     with an asterisk (*): (DEFVAR *GLOBAL-VARIABLE*)   
  797.     Some programmers will mark the beginning and end of an internal
  798.     global variable with a percent (%) or a period (.).
  799.     Make the names of constants begin and end with a plus (+):
  800.     (DEFCONSTANT +E+ 2.7182818)
  801.     This helps distinguish them from lexical variables. Some people
  802.     prefer to use macros to define constants, since this avoids
  803.     the problem of accidentally trying to bind a symbol declared
  804.     with defconstant.
  805.  
  806.       - If your program is built upon an underlying substrate which is
  807.     implementation-dependent, consider naming those functions and
  808.     macros in a way that visually identifies them, either by placing
  809.     them in their own package, or prepending a character like a %, ., 
  810.     or ! to the function name. Note that many programmers use the
  811.     $ as a macro character for slot access, so it should be avoided
  812.     unless you're using it for that purpose.
  813.  
  814.       - Don't use property lists. Instead, use an explicit hash table.
  815.     This helps avoid problems caused by the symbol being in the wrong
  816.     package, accidental reuse of property keys from other
  817.     programs, and allows you to customize the structure of the table. 
  818.  
  819.       - Use the most specific construct that does the job. This lets
  820.     readers of the code see what you intended when writing the code.
  821.     For example, don't use SETF if SETQ will do (e.g., for lexical
  822.     variables). Use the most specific predicate to test your conditions.
  823.     If you intend for a function to be a predicate, have it return T
  824.     for true, not just non-NIL. 
  825.  
  826.       - When NIL is used as an empty list, use () in your code. When NIL
  827.     is used as a boolean, use NIL. Similarly, use NULL to test for an
  828.     empty list, NOT to test a logical value. Use ENDP to test for the
  829.     end of a list, not NULL.
  830.  
  831.       - Don't use the &AUX lambda-list keyword. It is always clearer to
  832.     define local variables using LET or LET*.
  833.  
  834.       - When using RETURN and RETURN-FROM to exit from a block, don't
  835.     use (VALUES ..) when returning only one value, except if you
  836.     are using it to suppress extra multiple values from the first
  837.     argument. 
  838.  
  839.       - If you want a function to return no values (i.e., equivalent to
  840.     VOID in C), use (VALUES) to return zero values. This signals
  841.     to the reader that the function is used mainly for side-effects.
  842.  
  843.       - (VALUES (VALUES 1 2 3)) returns only the first value, 1.
  844.     You can use (VALUES (some-multiple-value-function ..)) to suppress
  845.     the extra multiple values from the function. Use MULTIPLE-VALUE-PROG1
  846.     instead of PROG1 when the multiple values are significant.
  847.  
  848.       - When using MULTIPLE-VALUE-BIND and DESTRUCTURING-BIND, don't rely
  849.     on the fact that NIL is used when values are missing. This is
  850.     an error in some implementations of DESTRUCTURING-BIND. Instead,
  851.     make sure that your function always returns the proper number of
  852.     values.
  853.  
  854.       - Type the name of external symbols, functions, and variables
  855.     from the COMMON-LISP package in uppercase. This will allow your
  856.     code to work properly in a case-sensitive version of Common Lisp,
  857.     since the print-names of symbols in the COMMON-LISP package
  858.     are uppercase internally. (However, not everybody feels that
  859.     being nice to case-sensitive Lisps is a requirement, so this
  860.     isn't an absolute style rule, just a suggestion.)
  861.  
  862.     Lisp Idioms:
  863.  
  864.       - MAPCAN is used with a function to return a variable number of
  865.     items to be included in an output list. When the function returns zero
  866.     or one items, the function serves as a filter. For example,
  867.        (mapcan #'(lambda (x) (when (and (numberp x) (evenp x)) (list x)))
  868.            '(1 2 3 4 x 5 y 6 z 7))
  869.  
  870.     Documentation:
  871.  
  872.       - Comment your code. Use three semicolons in the left margin before
  873.     the definition for major explanations. Use two semicolons that
  874.     float with the code to explain the routine that follows. Two
  875.     semicolons may also be used to explain the following line when the
  876.     comment is too long for the single semicolon treatment. Use
  877.     a single semicolon to the right of the code to explain a particular
  878.     line with a short comment. The number of semicolons used roughly
  879.     corresponds with the length of the comment. Put at least one blank
  880.     line before and after top-level expressions.
  881.  
  882.       - Include documentation strings in your code. This lets users
  883.     get help while running your program without having to resort to
  884.     the source code or printed documentation. 
  885.  
  886.    Issues related to macros:
  887.  
  888.       - Never use a macro instead of a function for efficiency reasons.
  889.     Declaim the function as inline -- for example, 
  890.       (DECLAIM (INLINE ..))
  891.     This is *not* a magic bullet -- be forewarned that inline
  892.     expansions can often increase the code size dramatically. INLINE
  893.     should be used only for short functions where the tradeoff is
  894.     likely to be worthwhile: inner loops, types that the compiler
  895.     might do something smart with, and so on.
  896.  
  897.       - When defining a macro that provides an implicit PROGN, use the
  898.     &BODY lambda-list keyword instead of &REST.
  899.  
  900.       - Use gensyms for bindings within a macro, unless the macro lets
  901.     the user explicitly specify the variable. For example:
  902.         (defmacro foo ((iter-var list) body-form &body body)
  903.           (let ((result (gensym "RESULT")))
  904.         `(let ((,result nil))
  905.            (dolist (,iter-var ,list ,result)
  906.              (setq ,result ,body-form)
  907.              (when ,result
  908.             ,@body)))))       
  909.     This avoids errors caused by collisions during macro expansion
  910.     between variable names used in the macro definition and in the
  911.     supplied body.
  912.  
  913.       - Use a DO- prefix in the name of a macro that does some kind of
  914.     iteration, WITH- when the macro establishes bindings, and
  915.     DEFINE- or DEF- when the macro creates some definitions. Don't
  916.     use the prefix MAP- in macro names, only in function names.
  917.  
  918.       - Don't create a new iteration macro when an existing function
  919.     or macro will do.
  920.  
  921.       - Don't define a macro where a function definition will work just
  922.     as well -- remember, you can FUNCALL or MAPCAR a function but 
  923.     not a macro.
  924.  
  925.       - The LOOP and SERIES macros generate efficient code. If you're
  926.     writing a new iteration macro, consider learning to use one
  927.     of them instead.
  928.   
  929.    File Modularization:
  930.  
  931.       - If your program involves macros that are used in more than one
  932.     file, it is generally a good idea to put such macros in a separate
  933.     file that gets loaded before the other files. The same things applies
  934.     to primitive functions. If a macro is complicated, the code that
  935.     defines the macro should be put into a file by itself. In general, if
  936.     a set of definitions form a cohesive and "independent" whole, they
  937.     should be put in a file by themselves, and maybe even in their own
  938.     package. It isn't unusual for a large Lisp program to have files named
  939.     "site-dependent-code", "primitives.lisp", and "macros.lisp". If a file
  940.     contains primarily macros, put "-macros" in the name of the file.
  941.  
  942.    Stylistic preferences:
  943.  
  944.       - Use (SETF (CAR ..) ..) and (SETF (CDR ..) ..) in preference to
  945.     RPLACA and RPLACD. Likewise (SETF (GET ..) ..) instead of PUT.
  946.  
  947.       - Use INCF, DECF, PUSH and POP instead instead of the corresponding
  948.     SETF forms.
  949.  
  950.       - Many programmers religiously avoid using CATCH, THROW, BLOCK,
  951.     PROG, GO and TAGBODY.  Tags and go-forms should only be necessary
  952.     to create extremely unusual and complicated iteration constructs. In
  953.     almost every circumstance, a ready-made iteration construct or
  954.     recursive implementation is more appropriate.
  955.  
  956.       - Don't use LET* where LET will do. Don't use LABELS where FLET
  957.     will do. Don't use DO* where DO will do.
  958.  
  959.       - Don't use DO where DOTIMES or DOLIST will do.
  960.  
  961.       - If you like using MAPCAR instead of DO/DOLIST, use MAPC when
  962.     no result is needed -- it's more efficient, since it doesn't
  963.     cons up a list. If a single cumulative value is required, use
  964.     REDUCE. If you are seeking a particular element, use FIND,
  965.     POSITION, or MEMBER.
  966.  
  967.       - If using REMOVE and DELETE to filter a sequence, don't use the
  968.     :test-not keyword or the REMOVE-IF-NOT or DELETE-IF-NOT functions.
  969.     Use COMPLEMENT to complement the predicate and the REMOVE-IF
  970.     or DELETE-IF functions instead.
  971.  
  972.       - Use complex numbers to represent points in a plane.
  973.  
  974.       - Don't use lists where vectors are more appropriate. Accessing the
  975.     nth element of a vector is faster than finding the nth element
  976.     of a list, since the latter requires pointer chasing while the
  977.     former requires simple addition. Vectors also take up less space
  978.     than lists. Use adjustable vectors with fill-pointers to
  979.     implement a stack, instead of a list -- using a list continually
  980.     conses and then throws away the conses.
  981.  
  982.       - When adding an entry to an association list, use ACONS, not
  983.     two calls to CONS. This makes it clear that you're using an alist.
  984.  
  985.       - If your association list has more than about 10 entries in it,
  986.     consider using a hash table. Hash tables are often more efficient.
  987.  
  988.       - When you don't need the full power of CLOS, consider using
  989.     structures instead. They are often faster, take up less space, and
  990.     easier to use.
  991.  
  992.       - Use PRINT-UNREADABLE-OBJECT when writing a print-function.
  993.  
  994.       - Use WITH-OPEN-FILE instead of OPEN and CLOSE.
  995.  
  996.       - When a HANDLER-CASE clause is executed, the stack has already
  997.     unwound, so dynamic bindings that existed when the error
  998.     occured may no longer exist when the handler is run. Use
  999.     HANDLER-BIND if you need this. 
  1000.  
  1001.       - When using CASE and TYPECASE forms, if you intend for the form
  1002.     to return NIL when all cases fail, include an explicit OTHERWISE
  1003.     clause. If it would be an error to return NIL when all cases
  1004.     fail, use ECASE, CCASE, ETYPECASE or CTYPECASE instead.
  1005.  
  1006.       - Use local variables in preference to global variables whenever
  1007.     possible. Do not use global variables in lieu of parameter passing.
  1008.     Global variables can be used in the following circumstances:
  1009.       *  When one function needs to affect the operation of
  1010.          another, but the second function isn't called by the first.
  1011.          (For example, *load-pathname* and *break-on-warnings*.)
  1012.       *  When a called function needs to affect the current or future
  1013.          operation of the caller, but it doesn't make sense to accomplish
  1014.          this by returning multiple values.
  1015.       *  To provide hooks into the mechanisms of the program.
  1016.          (For example, *evalhook*, *, /, and +.)
  1017.       *  Parameters which, when their value is changed, represent a
  1018.          major change to the program.
  1019.          (For example, *print-level* and *print-readably*.)
  1020.       *  For state that persists between invocations of the program.
  1021.          Also, for state which is used by more than one major program.
  1022.          (For example, *package*, *readtable*, *gensym-counter*.)
  1023.       *  To provide convenient information to the user.
  1024.          (For example, *version* and *features*.)
  1025.       *  To provide customizable defaults. 
  1026.          (For example, *default-pathname-defaults*.)
  1027.       *  When a value affects major portions of a program, and passing
  1028.          this value around would be extremely awkward. (The example
  1029.          here is output and input streams for a program. Even when
  1030.          the program passes the stream around as an argument, if you
  1031.          want to redirect all output from the program to a different
  1032.          stream, it is much easier to just rebind the global variable.)
  1033.  
  1034.       - Beginning students, especially ones accustomed to programming
  1035.     in C, Pascal, or Fortran, tend to use global variables to hold or pass
  1036.     information in their programs. This style is considered ugly by
  1037.     experienced Lisp programmers. Although assignment statements can't
  1038.     always be avoided in production code, good programmers take advantage
  1039.     of Lisp's functional programming style before resorting to SETF and
  1040.     SETQ. For example, they will nest function calls instead of using a
  1041.     temporary variable and use the stack to pass multiple values. When
  1042.     first learning to program in Lisp, try to avoid SETF/SETQ and their
  1043.     cousins as much as possible. And if a temporary variable is necessary,
  1044.     bind it to its first value in a LET statement, instead of letting it
  1045.     become a global variable by default. (If you see lots of compiler
  1046.     warnings about declaring variables to be special, you're probably
  1047.     making this mistake. If you intend a variable to be global, it should
  1048.     be defined with a DEFVAR or DEFPARAMETER statement, not left to the
  1049.     compiler to fix.)
  1050.  
  1051.    Correctness and efficiency issues:
  1052.  
  1053.       - In CLtL2, IN-PACKAGE does not evaluate its argument. Use defpackage
  1054.     to define a package and declare the external (exported)
  1055.     symbols from the package. 
  1056.  
  1057.       - The ARRAY-TOTAL-SIZE-LIMIT may be as small as 1024, and the
  1058.     CALL-ARGUMENTS-LIMIT may be as small as 50. 
  1059.  
  1060.       - Novices often mistakenly quote the conditions of a CASE form.
  1061.     For example, (case x ('a 3) ..) is incorrect. It would return
  1062.     3 if x were the symbol QUOTE. Use (case x (a 3) ..) instead.
  1063.  
  1064.       - Avoid using APPLY to flatten lists. (apply #'append list-of-lists)
  1065.     is compiled into a function call, and can run into problems with
  1066.     the CALL-ARGUMENTS-LIMIT. Use REDUCE or MAPCAR instead:
  1067.        (reduce #'append list-of-lists :from-end t)
  1068.        (mapcan #'copy-list list-of-lists)
  1069.     The second will often be more efficient (see note below about choosing
  1070.     the right algorithm). Beware of calls like (apply f (mapcar ..)).
  1071.  
  1072.       - NTH must cdr down the list to reach the elements you are
  1073.     interested in. If you don't need the structural flexibility of
  1074.     lists, try using vectors and the ELT function instead.
  1075.  
  1076.       - CASE statements can be vectorized if the keys are consecutive
  1077.     numbers. Such CASE statements can still have OTHERWISE clauses.
  1078.     To take advantage of this without losing readability, use #. with 
  1079.     symbolic constants:
  1080.  
  1081.         (eval-when (compile load eval)
  1082.            (defconstant RED 1)
  1083.            (defconstant GREEN 2)
  1084.            (defconstant BLUE 3))
  1085.  
  1086.         (case color
  1087.           (#.RED   ...)
  1088.           (#.GREEN ...)
  1089.           (#.BLUE  ...)
  1090.           ...)
  1091.  
  1092.       - Don't use quoted constants where you might later destructively
  1093.     modify them. For example, instead of writing '(c d) in
  1094.        (defun foo ()
  1095.          (let ((var '(c d)))
  1096.            ..))
  1097.     write (list 'c 'd) instead. Using a quote here can lead to
  1098.     unexpected results later. If you later destructively modify the 
  1099.     value of var, this is self-modifying code! Some Lisp compilers
  1100.     will complain about this, since they like to make constants
  1101.     read-only. Modifying constants has undefined results in ANSI CL.
  1102.     See also the answer to question [3-13].
  1103.  
  1104.     Similarly, beware of shared list structure arising from the use
  1105.     of backquote. Any sublist in a backquoted expression that doesn't
  1106.     contain any commas can share with the original source structure.
  1107.  
  1108.       - Don't proclaim unsafe optimizations, such as
  1109.        (proclaim '(optimize (safety 0) (speed 3) (space 1))) 
  1110.     since this yields a global effect. Instead, add the
  1111.     optimizations as local declarations to small pieces of
  1112.     well-tested, performance-critical code:
  1113.        (defun well-tested-function ()
  1114.           (declare (optimize (safety 0) (speed 3) (space 1)))
  1115.          ..)
  1116.     Such optimizations can remove run-time type-checking; type-checking
  1117.     is necessary unless you've very carefully checked your code
  1118.     and added all the appropriate type declarations.
  1119.  
  1120.       - Some programmers feel that you shouldn't add declarations to
  1121.     code until it is fully debugged, because incorrect
  1122.     declarations can be an annoying source of errors. They recommend
  1123.     using CHECK-TYPE liberally instead while you are developing the code.
  1124.     On the other hand, if you add declarations to tell the
  1125.     compiler what you think your code is doing, the compiler can
  1126.     then tell you when your assumptions are incorrect.
  1127.     Declarations also make it easier for another programmer to read
  1128.     your code. 
  1129.  
  1130.       - Declaring the type of variables to be FIXNUM does not
  1131.     necessarily mean that the results of arithmetic involving the 
  1132.     fixnums will be a fixnum; it could be a BIGNUM. For example,
  1133.        (declare (type fixnum x y))
  1134.        (setq z (+ (* x x) (* y y)))
  1135.     could result in z being a BIGNUM. If you know the limits of your
  1136.     numbers, use a declaration like
  1137.        (declare (type (integer 0 100) x y))
  1138.     instead, since most compilers can then do the appropriate type
  1139.     inference, leading to much faster code.
  1140.  
  1141.       - Don't change the compiler optimization with an OPTIMIZE
  1142.     proclamation or declaration until the code is fully debugged
  1143.     and profiled.  When first writing code you should say 
  1144.     (declare (optimize (safety 3))) regardless of the speed setting.
  1145.  
  1146.       - Depending on the optimization level of the compiler, type
  1147.     declarations are interpreted either as (1) a guarantee from
  1148.     you that the variable is always bound to values of that type,
  1149.     or (2) a desire that the compiler check that the variable is
  1150.     always bound to values of that type. Use CHECK-TYPE if (2) is
  1151.     your intention.
  1152.  
  1153.       - If you get warnings about unused variables, add IGNORE
  1154.     declarations if appropriate or fix the problem. Letting such
  1155.     warnings stand is a sloppy coding practice.
  1156.  
  1157.    To produce efficient code,
  1158.  
  1159.       - choose the right algorithm. For example, consider seven possible
  1160.     implementations of COPY-LIST:
  1161.  
  1162.        (defun copy-list (list)
  1163.          (let ((result nil))
  1164.            (dolist (item list result)
  1165.          (setf result (append result (list item))))))
  1166.  
  1167.        (defun copy-list (list)
  1168.          (let ((result nil))
  1169.            (dolist (item list (nreverse result))
  1170.          (push item result))))
  1171.  
  1172.        (defun copy-list (list)
  1173.          (mapcar #'identity list))
  1174.  
  1175.        (defun copy-list (list)
  1176.          (let ((result (make-list (length list))))
  1177.            (do ((original list (cdr original))
  1178.             (new result (cdr new)))
  1179.            ((null original) result)
  1180.          (setf (car new) (car original)))))
  1181.  
  1182.        (defun copy-list (list)
  1183.          (when list
  1184.            (let* ((result (list (car list)))
  1185.               (tail-ptr result))
  1186.          (dolist (item (cdr list) result)
  1187.            (setf (cdr tail-ptr) (list item))
  1188.            (setf tail-ptr (cdr tail-ptr))))))
  1189.     
  1190.         (defun copy-list (list)
  1191.           (loop for item in list collect item))
  1192.  
  1193.         (defun copy-list (list)
  1194.           (if (consp list) 
  1195.           (cons (car list)
  1196.             (copy-list (cdr list)))
  1197.           list))
  1198.  
  1199.     The first uses APPEND to tack the elements onto the end of the list.
  1200.     Since APPEND must traverse the entire partial list at each step, this
  1201.     yields a quadratic running time for the algorithm.  The second
  1202.     implementation improves on this by iterating down the list twice; once
  1203.     to build up the list in reverse order, and the second time to reverse
  1204.     it. The efficiency of the third depends on the Lisp implementation,
  1205.     but it is usually similar to the second, as is the fourth.  The fifth
  1206.     algorithm, however, iterates down the list only once. It avoids the
  1207.     extra work by keeping a pointer (reference) to the last cons of the 
  1208.     list and RPLACDing onto the end of that. Use of the fifth algorithm 
  1209.     may yield a speedup. Note that this contradicts the earlier dictum to
  1210.     avoid destructive functions. To make more efficient code one might
  1211.     selectively introduce destructive operations in critical sections of
  1212.     code. Nevertheless, the fifth implementation may be less efficient in
  1213.     Lisps with cdr-coding, since it is more expensive to RPLACD cdr-coded
  1214.     lists. Depending on the implementation of nreverse, however,
  1215.     the fifth and second implementations may be doing the same
  1216.     amount of work. The sixth example uses the Loop macro, which usually
  1217.     expands into code similar to the third. The seventh example copies
  1218.     dotted lists, and runs in linear time, but isn't tail-recursive. 
  1219.  
  1220.       - use type declarations liberally in time-critical code, but
  1221.     only if you are a seasoned Lisp programmer. Appropriate type
  1222.     declarations help the compiler generate more specific and
  1223.     optimized code. It also lets the reader know what assumptions
  1224.     were made. For example, if you only use fixnum arithmetic,
  1225.     adding declarations can lead to a significant speedup. If you
  1226.     are a novice Lisp programmer, you should use type declarations
  1227.     sparingly, as there may be no checking to see if the
  1228.     declarations are correct, and optimized code can be harder to
  1229.     debug. Wrong declarations can lead to errors in otherwise
  1230.     correct code, and can limit the reuse of code in other
  1231.     contexts. Depending on the Lisp compiler, it may also 
  1232.     be necessary to declare the type of results using THE, since
  1233.     some compilers don't deduce the result type from the inputs.
  1234.  
  1235.       - check the code produced by the compiler by using the
  1236.     disassemble function
  1237.  
  1238. ----------------------------------------------------------------
  1239. Subject: [1-4] Where can I learn about implementing Lisp interpreters 
  1240.            and compilers?
  1241.  
  1242. Books about Lisp implementation include:
  1243.  
  1244.    1. John Allen
  1245.       "Anatomy of Lisp"
  1246.       McGraw-Hill, 1978. 446 pages. ISBN 0-07-001115-X
  1247.  
  1248.    2. Samuel Kamin
  1249.       "Programming Languages, An Interpreter-Based Approach"
  1250.       Addison-Wesley, Reading, Mass., 1990. ISBN 0-201-06824-9
  1251.        Includes sources to several interpreters for Lisp-like
  1252.        languages, and a pointer to sources via anonymous ftp.
  1253.  
  1254.    3. Sharam Hekmatpour
  1255.       "Lisp: A Portable Implementation"
  1256.       Prentice Hall, 1985. ISBN 0-13-537490-X.
  1257.        Describes a portable implementation of a small dynamic
  1258.        Lisp interpreter (including C source code). 
  1259.  
  1260.    4. Peter Henderson
  1261.       "Functional Programming: Application and Implementation"
  1262.       Prentice-Hall (Englewood Cliffs, NJ), 1980. 355 pages.
  1263.  
  1264.    5. Peter M. Kogge
  1265.       "The Architecture of Symbolic Computers"
  1266.       McGraw-Hill, 1991. ISBN 0-07-035596-7.
  1267.        Includes sections on memory management, the SECD and
  1268.        Warren Abstract Machines, and overviews of the various
  1269.        Lisp Machine architectures.
  1270.    
  1271.    6. Daniel P. Friedman, Mitchell Wand, and Christopher T. Haynes
  1272.       "Essentials of Programming Languages"
  1273.       MIT Press, 1992, 536 pages. ISBN 0-262-06145-7.
  1274.        Teaches fundamental concepts of programming language
  1275.        design by using small interpreters as examples. Covers
  1276.        most of the features of Scheme. Includes a discussion
  1277.        of parameter passing techniques, object oriented languages,
  1278.        and techniques for transforming interpreters to allow
  1279.        their implementation in terms of any low-level language.
  1280.        Also discusses scanners, parsers, and the derivation of
  1281.        a compiler and virtual machine from an interpreter.
  1282.        Source files available by anonymous ftp from cs.indiana.edu
  1283.        in the directory /pub/eopl (129.79.254.191).
  1284.  
  1285.    7. Peter Lee, editor, "Topics in Advanced Language Implementation",
  1286.       The MIT Press, Cambridge, Mass., 1991.
  1287.        Articles relevant to the implementation of functional
  1288.        programming languages.
  1289.  
  1290.    8. Also see the proceedings of the biannual ACM Lisp and Functional
  1291.       Programming conferences, the implementation notes for CMU Common Lisp,
  1292.       Norvig's book, and SICP (Abelson & Sussman).
  1293.  
  1294. ----------------------------------------------------------------
  1295. Subject: [1-5]    What does CLOS, PCL, X3J13, CAR, CDR, ... mean? 
  1296.  
  1297. Glossary of acronyms:
  1298.    CAR           Originally meant "Contents of Address portion of Register",
  1299.            which is what CAR actually did on the IBM 704.
  1300.    CDR           Originally meant "Contents of Decrement portion of 
  1301.            Register", which is what CDR actually did
  1302.            on the IBM 704. Pronounced "Cudder".
  1303.    LISP           Originally from "LISt Processing"
  1304.    GUI           Graphical User Interface
  1305.    CLOS           Common Lisp Object System. The object oriented
  1306.            programming standard for Common Lisp. Based on
  1307.            Symbolics FLAVORS and Xerox LOOPS, among others.
  1308.            Pronounced either as "See-Loss" or "Closs". See also PCL.
  1309.    PCL           Portable Common Loops. A portable CLOS implementation.
  1310.            Available by anonymous ftp from parcftp.xerox.com:pcl/.
  1311.    LOOPS       Lisp Object Oriented Programming System. A predecessor
  1312.            to CLOS on Xerox Lisp machines.
  1313.    X3J13       Subcommittee of the ANSI committee X3 which is
  1314.            working on the ANSI Standardization of Common Lisp.
  1315.    ANSI           American National Standards Institute
  1316.    CL           Common Lisp
  1317.    SC22/WG16       The full name is ISO/IEC JTC 1/SC 22/WG 16. It stands
  1318.            for International Organization for
  1319.            Standardization/International Electronics(?)     
  1320.            Congress(?) Joint Technical Committee 1, Subcommittee 22,
  1321.            Working Group 16.  This long-winded name is the ISO
  1322.            working group working on an international Lisp standard,
  1323.            (i.e., the ISO analogue to X3J13).
  1324.    CLtL1       First edition of Guy Steele's book, 
  1325.            "Common Lisp the Language". 
  1326.    CLtL2       Second edition of Guy Steele's book,
  1327.            "Common Lisp the Language". 
  1328.  
  1329. ----------------------------------------------------------------
  1330. Subject: [1-6] Lisp Job Postings
  1331.  
  1332. The LISP-JOBS mailing list exists to help programmers find Lisp
  1333. programming positions, and to help companies with Lisp programming
  1334. positions find capable Lisp programmers. (Lisp here means Lisp-like
  1335. languages, including Scheme.)
  1336.  
  1337. Material appropriate for the list includes Lisp job announcements and
  1338. resumes from Lisp programmers (which should be sent only once) should
  1339. be sent to lisp-jobs@cis.ohio-state.edu.  Administrative requests (e.g., to be
  1340. added to the list) should be sent to lisp-jobs-request@cis.ohio-state.edu.
  1341.  
  1342. ----------------------------------------------------------------
  1343.  
  1344. ;;; *EOF*
  1345.